Dynamic name values

Dynamic name values are {PropertyName} placeholders used in string configuration fields throughout the provisioning system. At provisioning time each placeholder is replaced with the value of the corresponding property from the current provisioning context (e.g., the Excel row or integration system record).

{PropertyName} substitution

Any string configuration field that supports dynamic names accepts one or more {PropertyName} placeholders:

"{MatterName} ({MatterCode}) - {Responsible}"

Given a provisioning context where MatterName = "Smith v Jones", MatterCode = "M-2024-001", and Responsible = "jdoe@firm.com", the result is:

"Smith v Jones (M-2024-001) - jdoe@firm.com"

Each placeholder is resolved independently. If a key is not found in the context, the placeholder is removed (replaced with an empty string) and any resulting double separators (e.g. (), [], ( )) are also stripped.

URL-encoded placeholders

Placeholders encoded as %7BPropertyName%7D (URL-encoded { and }) are also resolved, which supports values pasted from URLs.

---

Built-in date tokens

The following tokens are always available regardless of the provisioning context:

Year

Token	Description	Example (2024)
{YYYY}	Full four-digit year	2024
{YY}	Last two digits	24
{YYYY-N}	Year minus N (1–29)	{YYYY-1} → 2023
{YYYY+N}	Year plus N (1–29)	{YYYY+2} → 2026
{YY-N}	Two-digit year minus N	{YY-1} → 23
{YY+N}	Two-digit year plus N	{YY+1} → 25

Month

Token	Description	Example (March)
{M}	Month number, no padding	3
{MM}	Month number, zero-padded	03
{MMM}	Abbreviated month name	Mar
{MMMM}	Full month name	March
{M-N} / {M+N}	Month number relative, no padding (1–12)	{M-1} → 2
{MM-N} / {MM+N}	Month number relative, zero-padded (1–12)	{MM+1} → 04
{MMM-N} / {MMM+N}	Abbreviated name relative (1–12)	{MMM-1} → Feb
{MMMM-N} / {MMMM+N}	Full name relative (1–12)	{MMMM+1} → April

Day

Token	Description	Example (5th)
{D}	Day of month, no padding	5
{DD}	Day of month, zero-padded	05
{DDD}	Abbreviated day name	Tue
{DDDD}	Full day name	Tuesday

Date token example

A folder naming pattern like {YYYY}-{MM} resolves to 2024-03 in March 2024. This is evaluated at the moment provisioning runs.

---

Configuration name matching

When a configuration object (e.g., SiteCollectionCfg, DocLibCfg) is looked up by a dynamic name template, the system generates multiple candidate names from that template and tries each one in order until a match is found. This allows you to create fallback or wildcard configuration entries for cases where some properties are missing or you want a single entry to cover many values.

Candidate generation

For a template like "{MatterType}-{Status}", the system generates candidates in this priority order:

1. Exact — all placeholders resolved with actual property values: "LIT-Open"
2. __ANY__ wildcards — one property replaced with __ANY__ per candidate, others use actual values: "LIT-__ANY__", "__ANY__-Open"
3. Power-set subsets — each non-empty subset of placeholders resolved, others removed: "LIT", "Open" (static text stripped after removal)
4. __EMPTY__ — properties that are missing or empty are replaced with __EMPTY__: "__EMPTY__-Open" (if MatterType is missing)
5. All keys removed — template resolved with no properties: "-" (static text only)

The first configuration whose Name matches any candidate wins.

Special name values

Value	Meaning
__ANY__	Matches when this property slot has any non-empty value. Use as a wildcard.
__EMPTY__	Matches when this property slot is missing or empty. Use as a fallback for missing data.

Examples

Single-property template: "{MatterType}"

Scenario	Candidates tried (in order)
MatterType = "LIT"	"LIT", "__ANY__", ""
MatterType = "" (empty)	"__EMPTY__", "__ANY__", ""
MatterType not in properties	"__EMPTY__", "__ANY__", ""

Configuration named "__ANY__" acts as a catch-all for any non-empty value. Configuration named "__EMPTY__" acts as a fallback when the property is absent or blank.

Two-property template: "{MatterType}-{Status}"

Given MatterType = "LIT", Status = "Open":

Candidate	Why
"LIT-Open"	Exact match
"LIT-__ANY__"	Status wildcard
"__ANY__-Open"	MatterType wildcard
"LIT"	Status removed
"Open"	MatterType removed
"__ANY__-__ANY__"	Both wildcards
"-"	Both removed

Given MatterType = "LIT", Status missing:

Candidate	Why
"LIT-__EMPTY__"	Status is missing
"LIT-__ANY__"	Status wildcard (still generated)
"__ANY__-__EMPTY__"	MatterType wildcard, Status missing
…	etc.

Practical configuration pattern

Name your configuration objects from most specific to most general:

"LIT-Open"           → applies only to open litigation matters
"LIT-__ANY__"        → applies to all litigation matters (any status)
"__ANY__-Open"       → applies to all open matters (any type)
"__ANY__-__ANY__"    → global fallback for any matter with both properties set
"__EMPTY__-__ANY__"  → fallback when MatterType is missing

The provisioning engine tries candidates in specificity order and stops at the first match.

---

DynamicFieldValueMapping

DynamicFieldValueMapping lets you remap the value of a specific field before it is substituted into the dynamic name. This is useful when the source system uses codes or abbreviations that should be translated to human-readable values (or vice versa) before they appear in SharePoint names or column values.

Configuration

Configured as SettingsCfg.DynamicFieldValueMapping (list) — an array of mapping entries, each targeting a specific field by name. Multiple entries can be defined to cover different fields.

Fields

Field	Type	Description
Name	string	The field name this mapping applies to (see Prefixes for scoping by context)
Mapping	NameValue (list)	List of source → target value pairs
UseUnknownValueIfNotFound	bool	When true, use UnknownValue if no mapping entry matches. When false (default), pass the original value through unchanged
UnknownValue	string	The fallback value used when UseUnknownValueIfNotFound is true and no match is found

Value matching

Each Mapping entry has a Name (the source value to match) and a Value (the replacement).

Exact match (case-insensitive):

{ "Name": "CORR", "Value": "Correspondence" }

"CORR" → "Correspondence", "corr" → "Correspondence".

Substring match using *pattern* wildcards:

{ "Name": "*draft*", "Value": "Draft" }

Any source value containing "draft" (case-insensitive) is modified: the matched substring is replaced by Value, while the rest of the original value is preserved.

Example: "draft-letter" → "Draft-letter" (not "Draft").

Exact match entries are checked first. Wildcard entries are only evaluated when no exact match is found.

Worked example with multiple fields

Configuration:

"DynamicFieldValueMapping": [
  {
    "Name": "MatterType",
    "Mapping": [
      { "Name": "LIT", "Value": "Litigation" },
      { "Name": "CORP", "Value": "Corporate" }
    ]
  },
  {
    "Name": "Status",
    "Mapping": [
      { "Name": "O", "Value": "Open" },
      { "Name": "C", "Value": "Closed" }
    ],
    "UseUnknownValueIfNotFound": true,
    "UnknownValue": "Unknown"
  }
]

Dynamic name template: "{MatterName} [{MatterType}] - {Status}"

Source values	Result
MatterName="Smith v Jones", MatterType="LIT", Status="O"	"Smith v Jones [Litigation] - Open"
MatterName="Acme Corp", MatterType="CORP", Status="C"	"Acme Corp [Corporate] - Closed"
MatterName="Misc Matter", MatterType="TAX", Status="X"	"Misc Matter [TAX] - Unknown"

In the third row, MatterType="TAX" has no mapping so the original value passes through; Status="X" has no mapping but UseUnknownValueIfNotFound is true so "Unknown" is used.

---

Prefixes

When a mapping should only apply in a specific context, prefix the Name with the context name followed by a dot. The lookup order is always:

1. {prefix}.{fieldName} — checked first when a prefix is active
2. {fieldName} — checked as fallback if no prefix-specific entry matches

A mapping without a prefix acts as the global default for that field name.

Integration prefixes

Integration plugins use a prefix equal to the integration name when resolving field values from their source system. Use these to apply remapping rules only for a specific integration.

Prefix	Integration
AFAS	AFAS accounting system
Aquilum	Aquilum case management
DataLEX	DataLEX case management
Datev	Datev accounting system
iManage	iManage document management (DeskSite and Work 10)
Jvris	Jvris case management
OpenText	OpenText document migration
Sisjuri	Sisjuri case management
SPMigration	SharePoint-to-SharePoint migration
TimeSolv	TimeSolv time/billing
Visma	Visma accounting system

Example: The iManage integration resolves DocumentClass using the prefix iManage, so a mapping named iManage.DocumentClass applies only during iManage migrations, while DocumentClass applies globally.

"DynamicFieldValueMapping": [
  {
    "Name": "iManage.DocumentClass",
    "Mapping": [
      { "Name": "CORR", "Value": "Correspondence" },
      { "Name": "PLEAD", "Value": "Pleadings" }
    ],
    "UseUnknownValueIfNotFound": true,
    "UnknownValue": "General"
  },
  {
    "Name": "DocumentClass",
    "Mapping": [
      { "Name": "CORR", "Value": "Correspondence" }
    ]
  }
]

Provisioning context prefixes

Several provisioning properties use a context prefix when resolving values. This allows the value to be remapped based on the context in which it is used, independently of the field names in the provisioning properties.

Prefix	Used when resolving
AutoNumber	Auto-number format string
ClientMatterDesign	Which site design template to apply to a matter/client site
ClientMatterServerRelativeUrl	Server-relative URL of the matter/client site collection
DoclibCompliance	Compliance label applied to a document library
ImportDocumentsFromTemplate	Source folder URL for importing documents from a template
MatterListFolderName	Folder name used in the matter list
Office365GroupChannelName	Display name of a Teams channel
Office365GroupVisibility	Visibility (Public/Private) of a Microsoft 365 Group
PageTemplateUrl	SharePoint page template URL
SiteCollectionTemplate	Site collection template identifier
Title	Site or library title computed from TitleFormatCustom

Example: Select the site structure based on a MatterType property in the provisioning context:

{
  "Name": "ClientMatterDesign.MatterType",
  "Mapping": [
    { "Name": "LIT", "Value": "MatterSiteCollection" },
    { "Name": "CORP", "Value": "MatterDocLib" }
  ],
  "UseUnknownValueIfNotFound": true,
  "UnknownValue": "MatterSite"
}

The Value must be a valid ClientMatterDesign enum value:

Value	Structure created
MatterSiteCollection	Dedicated site collection per matter
MatterSite	Sub-site under a shared site collection
MatterDocLib	Document library inside an existing site
ClientSiteCollection_MatterSite	Client site collection with a matter sub-site
ClientSiteCollection_MatterDocLib	Client site collection with a matter document library
ClientSite_MatterSite	Client sub-site with a matter sub-site
ClientSite_MatterDocLib	Client sub-site with a matter document library
MatterOffice365Group	Microsoft 365 Group per matter

Note on unmatched values: If UseUnknownValueIfNotFound is false (the default) and the source value has no mapping entry, the raw source value is passed through unchanged (e.g. "TAX"). What happens next depends on whether that value is empty or not:

• Empty result — if the placeholder resolves to an empty string (e.g. the property is missing), ClientMatterDesign is left unchanged and the value configured directly in SharepointCfg is used as the fallback.
• Non-empty invalid value — if the raw value is a non-empty string that is not a valid ClientMatterDesign enum member, enum parsing throws an exception and provisioning fails.

Use UseUnknownValueIfNotFound: true with a valid enum UnknownValue to guarantee a safe fallback for any unrecognised source value.

When the provisioning engine resolves ClientMatterDesign, it checks ClientMatterDesign.MatterType first, then falls back to MatterType globally if no prefix-specific entry matches.

Boolean fields

Some configuration fields are typed as string but interpreted as bool at runtime (e.g. Office365GroupCfg.Team, Office365GroupCfg.Yammer, Office365GroupCfg.VisibilityPrivate). The resolved string is converted to a boolean using ToOrDefault<bool>, which recognises these truthy values (case-insensitive):

true, 1, yes, y, j, ja, on, checked

Any other value — including an empty string — converts to false without throwing an exception.

Example: Create a Microsoft Teams team only for matters where a Classified property is set, mapping "yes" / "no" source values from the provisioning system to valid boolean strings:

Office365GroupCfg.Team is set to "{Classified}". The DynamicFieldValueMapping entry (no prefix needed because Team is not a provisioning context prefix — the field is used as a plain template):

{
  "Name": "Classified",
  "Mapping": [
    { "Name": "yes", "Value": "true" },
    { "Name": "no",  "Value": "false" }
  ],
  "UseUnknownValueIfNotFound": true,
  "UnknownValue": "false"
}

{Classified} is resolved from the provisioning properties, the mapping translates "yes" → "true" (Team created) and "no" → "false" (no Team). Because ToOrDefault<bool> is used, an unrecognised or empty value silently falls back to false — no exception is thrown.

---

Related

• Global Settings Configuration — where DynamicFieldValueMapping is configured (SettingsCfg)
• SharepointCfg — root configuration